home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000134_owner-urn-ietf _Tue Nov 12 11:19:24 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20237 for urn-ietf-out; Tue, 12 Nov 1996 11:19:24 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20217 for <urn-ietf@services.bunyip.com>; Tue, 12 Nov 1996 11:19:09 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA01726  (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:19:03 -0500
  5. Message-Id: <9611121619.AA01726@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Tue Nov 12 10:18 CST 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "Dirk.vanGulik@jrc.it" <Dirk.vanGulik@jrc.it>,
  9.         "Harald.T.Alvestrand@uninett.no" <Harald.T.Alvestrand@uninett.no>
  10. Cc: "FisherM@is3.indy.tce.com" <FisherM@is3.indy.tce.com>,
  11.         "girod@LCS.MIT.EDU" <girod@LCS.MIT.EDU>,
  12.         "mduerst@ifi.unizh.ch" <mduerst@ifi.unizh.ch>,
  13.         "moore@cs.utk.edu" <moore@cs.utk.edu>,
  14.         "tallen@fsc.fujitsu.com" <tallen@fsc.fujitsu.com>,
  15.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  16. Date: Tue, 12 Nov 96 10:19:43 
  17. Priority: Normal
  18. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  19. Mime-Version: 1.0
  20. Content-Type: text/plain; charset="us-ascii"
  21. Content-Transfer-Encoding: 7bit
  22. Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
  23. Sender: owner-urn-ietf@services.bunyip.com
  24. Precedence: bulk
  25. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  26. Errors-To: owner-urn-ietf@bunyip.com
  27.  
  28. On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote:
  29.  
  30. >> To me, the extension (as written) has a couple of holes.  The URN has to have
  31. >> information about the namespace so that the resolver can resolve the URN
  32. >> correctly (it took me a while to realize that the proper parsing of option B is
  33. >> the second ":").  Therefore, having no meaning after the optional "urn:"
  34. >> doesn't work.
  35. >
  36. >I realized this as well; but was (and still am) unsure how to effectuate this;
  37. >because is implies that the bit between the first to ':' is really limited in
  38. >encoding. Something which has bothered me in the syntax document. But I have
  39. >no immediate solution for it.
  40.  
  41. This is on purpose.  The more you free up the NID encoding, the more you restrict
  42. potential implementations.
  43.  
  44. >Well: (Which each char actualy being an octet, etc..)
  45. >
  46. >    [<] urn:NS:OPS [>]
  47. >
  48. >    NS consists of A..Z, 0..9
  49. >    OPS consists of A..Z, 0..9, '-', '_' and '.'
  50. >
  51. >    The '-','_','.' are kept in reserve for the NS
  52. >
  53. >    Whitespace is allowed
  54. >
  55. >Would be kind of simple.
  56.  
  57. Yes, and we may reach something like this eventually (there would
  58. have to be more characters added to the NSS to support grandfathered
  59. spaces.  There are just some tradeoffs that we would have to agree upon.
  60.  
  61. >> >A
  62. >> >> - The URN syntax doc says that URNs are sequences of ASCII
  63. >> >>   characters (or some subset thereof)
  64. >> 
  65. >> This is of course, the simplest.  A minimum of transport encoding would be
  66. >> involved.  There may be some reserved characters that would be need to be
  67. >> encoded on a namespace specific basis but those could be done with
  68. >> %HH encoding.
  69. >
  70. >Which would imply namespace specific encapsulation needs; which kind of imposes
  71. >external NS knowledge on arbritary clients.
  72.  
  73. Somebody will have to know this anyway.  I'm not saying that all the reserved characters
  74. have to be in the syntax document (in fact I'm saying they can't).  I'm saying that any
  75. reserved character should be encoded with %HH, which is slightly different.
  76.  
  77. >> >B
  78. >> >> - The URN syntax doc says that URNs are sequences of OCTETS,
  79. >> >>   with no meaning assigned by the URN syntax doc after the
  80. >> >>   second  ':'
  81. >> 
  82. >> I've modified the above to point up the ':' character.  This is the "opaque string"
  83. >> option.  This option would require some transport encoding for 8-bit unclean pipes.
  84. >> I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
  85. >> something like the %HH scheme would be needed.  For others, the %HH scheme
  86. >> could be mixed with actual glyphs that are representation of that octet (or sequence
  87. >> of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
  88. >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
  89. >> The other difficulty is that reserved characters have to be limited to
  90. >> a subset of ASCII or there is the possibility for encoding collisions that would require
  91. >> the syntax doc to specify its own encoding scheme.
  92. >> 
  93. >
  94. >Somehow not very practical ? IMHO.
  95.  
  96. I didn't say it was practical, just tried to state what the tradeoffs are.
  97.  
  98. Ryan
  99.  
  100. P.S.  Sorry folks, I think I was in such a hurry to send the last comment off that I
  101. didn't admit who wrote it.
  102.  
  103.